Conventional modem communication systems rely heavily on physical resources which are controlled by data processing devices, eg, switch fabrics, routers, frequency channel assignment apparatus, networked personal computers, network management systems and the like. Data processing devices typically operate in accordance with the known Von Neumann methods, in which a large number of logic elements eg, bi-stable devices, transistors or the like sequentially switch between states under control of (typically) electronic signals. Large collections of such signals comprise a know computer program. At a higher level, the individual signals which control individual logic devices are assembled from a set of instructions written in a known computer language. Such instructions are generically referred to as code. A conventional computer program may contain hundreds of thousands, to tens of millions of lines of code. For example, a main control program for the known DMS100 broad band switch manufactured by Northem Telecom Limited contains of the order of ten million individual lines of code and is written in a proprietary programming language. Programs of more modest length may typically have between one hundred thousand, and three million lines of code. In general, as computing resources become more powerful, and program developers take advantage of increased computing power to provide more and more features, there is a generalised tendency within both the Telecom's and computer industries for programs to become more and more complex, to contain greater numbers of lines of code.
In U.S. Pat. No. 5,428,729 (IBM) there is disclosed a data processing system having a plurality of workstations for generation of a software application package by a plurality of programmers under control or a metaprogrammer. An object of U.S. Pat No. 5,428,729 is to automate management of a design through the implementation of a software application.
In any communications system, whether packet switched or circuit switched, reliability and robustness are of primary concern, and due to the high dependency of communication systems on program control, de-bugging and improving programs by way of regular code inspections is of primary importance, and is an essential part of the construction process of any program.
The code inspection process operated at Nortel (Northem Telecom Limited) involves calling a meeting between a team of program developers responsible for a program or a section of a program in order that the code can be inspected, and any potential problem areas in the code identified. An overall development process for a program involves many such code inspection meetings. After each code inspection meeting, the developers attempt to modify or re-write any code lines for which they have responsibility, and which have been identified as being problematic or capable of improvement at the code inspection meeting.
Referring to FIG. 1 herein, there is illustrated in general a code inspection process. In an overall development cycle of a program, many such code inspection processes will occur on various components of a program. Regular code inspections during a program build have the direct advantages of increasing software quality, identifying errors early on in a development cycle, decreasing testing time, reducing reworking and improving efficiency of error detection. Indirect advantages include increases in customer satisfaction through better more reliable products.
Typically, a code inspection meeting is organised according to the following format:
Code inspection meetings occur for selected sections of code or modules of code of a program, not for a complete program. PA1 In step 100 a manager or program developer calls a code of inspection meeting, to be attended by a team of developers working on a particular portion of code, subject of the meeting. PA1 In step 101, prior to the code inspection meeting each developer photocopies a print out of the particular code portions on which they are working and for which they have responsibility. PA1 In step 102, typically, three or four developers will attend a code inspection meeting, and the code inspection meeting may last of the order of two hours. PA1 At the code inspection meeting, individual lines of code are inspected by all or some developers on a line-by-line basis. Each developer makes notes of any proposed changes to the particular portions of code for which they have responsibility. Responsibility for the overall progress of the meeting and responsibility for recording changes of code is designated to one developer or manager, who is known as a "moderator". PA1 In step 103, after the meeting the moderator, or one of the developers prepares typed or written minutes of the meeting identifying lines of code which are to be changed, and any proposed changes to that code. Then, one or more of the developers re-work the code The developer who is responsible for a particular portion of code makes the changes. PA1 Changes to the actual working copy of the program are not made at the meeting--these are to be carried out later by the individual developers. A re-work follow up meeting is optionally carried our in step 104. PA1 inputting pre-written code from an external source, and storing said code in a memory area; PA1 displaying said code on a visual display device; PA1 in response to inputs from a graphical user interface, modifying individual lines of said code; and PA1 for each modified line of code, displaying on said visual display device at least one respective icon identifying said line of code. PA1 inputting code comprising a plurality of code lines; PA1 displaying said plurality of code lines on a visual display device; PA1 inputting modifications to said code to produce modified code; PA1 displaying said modified code on said visual display device; and PA1 generating data describing said modified code. PA1 inputting annotation data describing annotations to said code lines; PA1 storing said annotation data to a memory device; and PA1 displaying said annotation data on said visual display device. PA1 an interface means for interfacing with a code development tool for input and output of said code; PA1 a display generation means for generating a plurality of displays of said code for display on said visual display device; PA1 a monitoring means for monitoring a result of a code inspection process; and PA1 a report data generation means for generating a report data describing a code inspection session. PA1 at a plurality of said graphical user interfaces, generating a display of original source code; PA1 at individual ones of said graphical user interfaces, entering annotation data describing annotations to said source code, each said annotation identifying a line number of said source code; PA1 sending said annotation data to a data storage device and storing said annotation data; PA1 generating a source code display on each of said graphical user interfaces, said source code display comprising a first display area for display of original source code, and a second display area for display of replicated source code; PA1 at each graphical user interface, scrolling said corresponding respective source code display such that all said source code displays are scrolled simultaneously and show a same common view; PA1 interrupting said scrolling process for entry of annotation data relating to source code displayed during said scrolling process; PA1 storing said annotation data entered during said interruptions; and PA1 terminating said scrolling process. PA1 data identifying a plurality of human operators; PA1 data describing a plurality of source code files; PA1 data describing an amount of new code lines in each of said source code files; PA1 data describing a proportion of original source code lines and new source code lines changed; PA1 data describing a number of annotation comments. PA1 data describing a type of annotation data; and PA1 an amount of annotations of each of said types. PA1 identifying source code lines having errors which affect overall operation of said source code; and PA1 storing annotation data describing said operation affecting errors. PA1 inputting pre-written code from an external source, and storing said code in a memory area; PA1 displaying said code on a visual display device; PA1 in response to inputs from a graphical user interface, entering data relating to individual lines of said code; and PA1 for each line of code for which data has been entered, displaying on said visual display device at least one respective icon identifying said line of code.
Although code inspection meetings are an essential part of building a program, there are several problems associated with such meetings. Firstly, good experienced program developers are scarce, and their time is valuable. Having three or four program developers spending time photocopying code, and having a program developer preparing minutes of a code inspection meeting is not an optimum use of their time. However, preparing material to bring along to a code inspection meeting is a skilled task, and therefore needs to be carried out by developers and is not easily delegated. Secondly, preparation of minutes of the meeting introduces a delay into product development, since programmers may not address problems identified at the code of inspection meeting until the typed up minutes of the meeting are available. Thirdly, developers may be situated at physically separate locations, for example either at different locations within a same building, within an area of a few hundred meters of each other at different sites a few miles or tens of miles apart, or in a multi-national organisation, developers may be located on different continents. In the latter case, it may only be practicable for a developer to `attend` a meeting by telephone conference call. Fourthly, there is the problem that the rate at which lines of code can be inspected is relatively low. For example, in a two hour meeting attended by four developers, where good progress is made, of the order of eight hundred to one thousand individual lines of code may be inspected (a good rate of code of inspection of around two hundred and fifty lines per developer hour). Thus, for a moderate size program of for example one hundred thousand lines of code, inspecting every line of code once would incur of the order of four hundred developer hours of code inspection meetings if a good rate of code inspection were achieved. However, such a code inspection overhead is unrealistic, since the necessary resource of developer time is unavailable, and if available, would be better utilized on other tasks. Further, it may be that some lines of code require more than one code inspection. For a large program, eg, ten million lines of code, it is not practicable to inspect every line of code, and in practice for most programs only 10 to 20% of lines of code are inspected, and it is accepted that there will be bugs and errors within programs. Typically, 20% pf the most complex code is responsible for of the order of 80% of all errors in a program. Complexity analysis tools are available for identifying the most complex portions of code. One such example is the QAC tool which is a C static analyzer which serves as a tool to help coders to check that their code adheres to recognized good practices. The QAC tool is able to wam of possible errors or bad practices not picked up by a compiler, as well as producing metrics on code which provide an indication of module complexity and maintainability.